home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0086 / 479.txt < prev    next >
Text File  |  1997-04-16  |  13KB  |  327 lines

  1.  
  2. INFO-ATARI16 Digest         Thu, 26 Apr 90       Volume 90 : Issue  479
  3.  
  4. Today's Topics:
  5.                extended commandline arguments (2 msgs)
  6.                              File Servers
  7.         Proposed change to names of sources/binaries postings
  8.                          ST and a Juki 6100?
  9.               summary of responses: changing resolutions
  10.                     The Phantom Typist - So What?
  11.                     yet another feature of TOS 1.4
  12.                   yet another little bug in TOS 1.4
  13. ----------------------------------------------------------------------
  14.  
  15. Date: Thu, 26 Apr 90 11:23:34 MSZ
  16. From: ONM07%DMSWWU1A.BITNET@CUNYVM.CUNY.EDU (Julian Reschke)
  17. Subject: extended commandline arguments
  18. Message-ID: <9004260823.AA03307@freya.dmswwu-ether>
  19.  
  20. In article <1650@electro.UUCP> Ignac Kolenko writes:
  21. > what is the most prevelant (sp?) extended commandline protocol used
  22. > in the Atari world. what i'm trying to get at is if it would be worth
  23. > bothering to implement the Atari Extended GEMDOS Commandline Argument
  24. > Spec posted by Ken B. many months ago, or implement something more
  25. > along the lines of the Mark Williams spec, since i am assuming that
  26. > MUCH more software can understand the latter, although the former is now
  27. > the de-facto Atari supported standard. So which would be better to
  28. > implement??
  29. That's easy. Ataris specification ist THE standard, so PLEASE use it.
  30. Other shells (Gemini 1.1, Master) do it, too!
  31.  
  32. ___________________________ cut here _____________________________________
  33. Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
  34. eMail: ONM07@DMSWWU1A.BITNET, "Julian Reschke" @ MAUS MS  (++49 251 77216)
  35. ____________________ correct me if I'm wrong _____________________________
  36.  
  37.  
  38. ------------------------------
  39.  
  40. Date: 25 Apr 90 17:45:21 GMT
  41. From: eru!luth!sunic!mcsun!unido!sbsvax!roeder@bloom-beacon.mit.edu  (Edgar
  42.  Roeder)
  43. Subject: extended commandline arguments
  44. Message-ID: <4054@sbsvax.cs.uni-sb.de>
  45.  
  46. In article <1650@electro.UUCP>, ignac@electro.UUCP (Ignac Kolenko) writes:
  47. >
  48. > what is the most prevelant (sp?) extended commandline protocol used
  49. > in the Atari world. what i'm trying to get at is if it would be worth
  50. > bothering to implement the Atari Extended GEMDOS Commandline Argument
  51. > Spec posted by Ken B. many months ago, or implement something more
  52. > along the lines of the Mark Williams spec, since i am assuming that
  53. > MUCH more software can understand the latter, although the former is now
  54. > the de-facto Atari supported standard. So which would be better to
  55. > implement??
  56. >
  57.  
  58. The Atari standard has inherent problems with any old software expecting the
  59. length byte in the basepage to be valid. Programming languages like Pascal or
  60. Modula might use it since their string format is exactly what Atari once
  61. documented as the format of the arguments in the basepage (one length byte
  62. plus the text of the string). You will get strange effects when a program
  63. gets the wrong value here.
  64.  
  65. You can observe the effect for example if you use the ff3 (file-finder) program
  66. posted some month ago in comp.binaries.atari.st with the Atari-standard (in the
  67. recently posted Master-demo for instance you can try out the Atari standard
  68. with "xargs 10" ?== 8 + 2 for length byte 127 + MWC arguments and handle 2 is
  69. console?). The display is at least very strange and almost unreadable (The file
  70. finder was compiled with Pascal!).
  71.  
  72. > if the Mark Williams spec is the better one to implement, then what exactly
  73. > is their spec. I know it's similar, but i need details ...
  74. >
  75.  
  76. The MWC standard uses a valid length byte and the value of the ARGV environment
  77. variable has a special meaning. It is interpreted as "i/o-vector". For any
  78. handle (from 0 to 20) the corresponding position in the i/o-vector is
  79.         A       if the handle points to AUX:,
  80.         C       if the handle is for CON:,
  81.         F       if the handle points to an open file,
  82.         P       if the handle refers to PRN: and
  83.         ?       if the type is unknown or no file is opened with this handle.
  84. The rest of the environment after ARGV=i/o-vector is a NUL-seperated list of the
  85. arguments passed to the program. I think the MWC-tools also pass 127 as length
  86. of the commandline (like the Atari specs say). So the only differences between
  87. MWC and Atari is the meaning of the value of ARGV (i/o-vector vs. no meaning)
  88. and possibly the passing of an invalid length byte (127) to validate the
  89. arguments.
  90.  
  91. Because of the problems mentioned above, you should at least give the user the
  92. opportunity to switch off the extended argument passing when using old progs
  93. expecting a valid length byte (and not checking wether it's reasonable).
  94.  
  95. > --
  96. > =====Ignac A. Kolenko (The Ig)=====watmath!watcgl!electro!brasoft!ignac======
  97. >      co-author of QuickST, and the entire line of Quick Software!!!!
  98. >   Branch Always Software Box 2624, Station B, Kitchener, Ont. CANADA N2H 6N2
  99. > =============================================================================
  100.  
  101.         - Edgar
  102. --
  103.  
  104. Mail:  Edgar R\"oder                    E-Mail: roeder@cs.uni-sb.de
  105.        Liesbet-Dill-Stra\ss e 3
  106. D-6602 Dudweiler                               -o-   -o-
  107.        W-Germany                                   ~
  108. Phone: 06897/74643                               '---'
  109.  
  110. ------------------------------
  111.  
  112. Date: 25 Apr 90 23:12:16 GMT
  113. From: zephyr.ens.tek.com!orca.wv.tek.com!pogo!bluneski@uunet.uu.net  (Bob
  114.  Luneski)
  115. Subject: File Servers
  116. Message-ID: <8965@pogo.WV.TEK.COM>
  117.  
  118. Does anyone know the address of an archive site with Atari ST files that
  119. has a file server for us poor folks without Internet ftp access??
  120.  
  121. Thanks a bunch,
  122. ____________________________________________________________________________
  123.   Bob Luneski
  124.   Diamond Back Support Hotline:  bluneski@pogo.WV.TEK.COM
  125.                                  Genie: B.LUNESKI1
  126.  
  127.   The opinions expressed herein are my own and in no way reflect the
  128.   opinions of Tektronix, Inc.
  129.  
  130. ------------------------------
  131.  
  132. Date: 25 Apr 90 10:09:42 GMT
  133. From: mcsun!inria!laas!ralph@uunet.uu.net  (Ralph P. Sobek)
  134. Subject: Proposed change to names of sources/binaries postings
  135. Message-ID: <RALPH.90Apr25120942@orion.laas.fr>
  136.  
  137. In article <1588@male.EBay.Sun.COM> koreth@panarthea.ebay.sun.com (Steven Grimm)
  138.  writes:
  139. |   Someone has suggested that since software to automatically save news
  140.  articles
  141. |   using the filename in the "Archive-name" pseudo-header line, I should stop
  142. |   calling the articles program/part01, program/part02, etc. and start calling
  143. |   them program/program.uaa, program/program.uab, and so on.  This would enable
  144. |   Dumas uud to pick up the parts effortlessly.
  145.  
  146. In article <11706@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu)
  147.  writes:
  148. |     No changes to the Dumas uud program are necessary. The program is pretty
  149. |     smart, it does a two-part search for the continuation files already. First
  150. |     it looks for the named file, e.g. program.uab, but if that file doesn't
  151. |     exist it merely continues to read its current input file. So, to decode a
  152. |     multipart posting, merely
  153. |          cat part* | uud
  154. |     and you get the output file, no muss & no fuss.
  155.  
  156. Rather than stop calling the articles program/part01 as Howard has
  157. suggested above and in <1599@lzsc.ATT.COM>, making references to the
  158. breaking of software, I suggest an alternate Article or Archive header
  159. in some form similar to:
  160.  
  161.         Filename: foobar.uaa
  162.  
  163. If an optional header is acceptable, a) current software would not be
  164. broken, and b) software could be written, by those who want this
  165. feature, to automatically save the file under the given name.
  166.  
  167. Wishlist:  for all those news hackers!!
  168.  
  169. What I would like, under either rn or gnus, is to be able to specify
  170. the articles which make up some piece of software, and then have the
  171. news software pipe the parts in the proper order to uud or unshar,
  172. since it can accept the parts on stdin.  That way, no more messy
  173. intermediate files to fiddle around with.
  174.  
  175. Oh well,
  176.  
  177. --
  178. Ralph P. Sobek                    Disclaimer: The above ruminations are my own.
  179. ralph@laas.fr                              Addresses are ordered by importance.
  180. ralph@laas.uucp, or ...!uunet!laas!ralph
  181. If all else fails, try:                               sobek@eclair.Berkeley.EDU
  182. ===============================================================================
  183. Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78
  184.  
  185. ------------------------------
  186.  
  187. Date: 24 Apr 90 12:06:46 GMT
  188. From: ncrlnk!ncrwic!wsuiar!mwjester@uunet.uu.net  (Max Jester)
  189. Subject: ST and a Juki 6100?
  190. Message-ID: <143.2633fb07@wsuiar.uucp>
  191.  
  192. In article <2864@ultb.isc.rit.edu>, clf3678@ultb.isc.rit.edu (C.L. Freemesser)
  193.  writes:
  194. > When I try to print with it, it doesn't do anything.  I've tried
  195. > different printer drivers with WordPerfect, including a Diablo 630 and
  196. > a regular ASCII text printer, but nothing works.
  197. >
  198. > I know the printer works because I tested it with an Osborne (don't
  199. > laugh) and it worked just fine.  However, the Osborne DID use it's
  200. > IEEE-488 port to drive the printer.  I know I can't use it for
  201. > desktop dumps, but SHOULD be usable with WP.
  202. >
  203. > Any ideas AT ALL are greatly appreciated!
  204.  
  205.   Not all printers using a Centronics-compatible hardware interface meet the
  206. timing specs required to work with the ST.  In particular, various 'off'
  207. brands seem prone to problems - e.g. the Olivetti electrostatic printer that
  208. DAK was selling several years ago.
  209.  
  210.   One possibility that may or may not help - a buffer.  For whatever reason,
  211. they frequently are more forgiving with respect to timing.  But I would try
  212. before I buy, unless you need one anyway.
  213.  
  214. Hope this helps.
  215.  
  216. Max J.
  217.  
  218. --Life is short.  Eat dessert first.
  219.  
  220. ------------------------------
  221.  
  222. Date: 25 Apr 90 22:01:27 GMT
  223. From:
  224.  swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!kjetilho@ucsd.edu
  225.  (Kjetil Torgrim Homme)
  226. Subject: summary of responses: changing resolutions
  227. Message-ID: <2930@ifi.uio.no>
  228.  
  229. A very simple solution:
  230. Use an editor that's not based on GEM... This should allow
  231. you to switch resoultion.
  232.  
  233. GEM only slows editors down anyway!!!
  234.  
  235.  
  236. Only my humble opinion,
  237.  
  238. Kjetil T.
  239.  
  240. ------------------------------
  241.  
  242. Date: 26 Apr 90 00:11:26 GMT
  243. From: ncs.dnd.ca!balkwill@rutgers.edu  (R. J. Balkwill)
  244. Subject: The Phantom Typist - So What?
  245. Message-ID: <877@ncs.dnd.ca>
  246.  
  247. I don't doubt that the PT exists - neither, I suspect, does Atari.
  248. But in all the flames I've read about this against Atari I haven't
  249. read anyone explicitly mentionning the fact that the programs in which
  250. this 'TOS' bug occur seem to all be ones that screw around with the
  251. system I/O vectors.  How else could Word Perfect (the most frequently
  252. cited example) offer you choices of how to enter the menu bar.
  253. Another program recently mentionned is Spectre, and I'm darned if I
  254. know how an emulator for another OS could AVOID screwing around with
  255. same.
  256.  
  257. The 68000 chip has a supervisor mode which could prevent any of this
  258. but TOS (or Gemdos) chooses to give the user access to supervisor mode
  259. specific operations such as changing vectors, or anything else for
  260. that matter.  When an application does these things how in Heaven's
  261. name do you expect the OS people to take responsibility.  Your machine
  262. isn't even executing their code!
  263.  
  264. As for WP, it's so full of bugs in the Atari version that one more, or
  265. a hundred more bugs wouldn't surprise me at all.  It especially does
  266. not like maccel2.prg which also has notions about how the mouse, and
  267. hence I/O in general, ought to be handled.  Still, since WP has given
  268. up on the Atari I guess some people just have to flame someone.
  269. ---
  270. Bob
  271.  
  272. ------------------------------
  273.  
  274. Date: 25 Apr 90 17:28:04 GMT
  275. From: att!dptg!lzsc!hcj@ucbvax.Berkeley.EDU  (HC Johnson)
  276. Subject: yet another feature of TOS 1.4
  277. Message-ID: <1669@lzsc.ATT.COM>
  278.  
  279. Yet another "feature" of TOS 1.4.
  280.  
  281. I use wildcards in desktop.inf to display only part of a folder.
  282. I find that two such, as in P*D*.prg does not work.  OK, so I'm limited
  283. to one *.
  284. Now I find that 2*.prg works, listing only programs starting with 2.
  285. BUT, *2.prg, which should find programs inding in 2, like pcditto2.prg,
  286. list none of these; but does list pc_d.2 !
  287.  
  288. Now that is a feature!
  289.  
  290. Howard C. Johnson
  291. ATT Bell Labs
  292. att!lzsc!hcj
  293. hcj@lzsc.att.com
  294.  
  295. ------------------------------
  296.  
  297. Date: 26 Apr 90 08:36:27 GMT
  298. From: mcsun!hp4nl!nikhefh!t19@uunet.uu.net  (Geert J v Oldenborgh)
  299. Subject: yet another little bug in TOS 1.4
  300. Message-ID: <837@nikhefh.nikhef.nl>
  301.  
  302. The GEMDOS cache does not seem to know whether a drive is mounted or not:
  303.  
  304. # create a 100 K ramdisk on g:
  305. $ ramdisk -c g 100
  306. $ touch g:/aap
  307. $ ls -altFv g:/
  308. g:/
  309. a----w          0  Apr-26-1990  10:32:06   aap
  310. Total 0 bytes in 1 files
  311. # destroy the ramdisk.
  312. $ ramdisk -d g
  313. $ df g
  314. g: drive not mounted
  315. # but .....
  316. $ ls -altFv g:/
  317. g:/
  318. a----w          0  Apr-26-1990  10:32:06   aap
  319. Total 0 bytes in 1 files
  320.  
  321. (though there is nothing much one can do with this file...)
  322.  
  323. ------------------------------
  324.  
  325. End of INFO-ATARI16 Digest V90 Issue #479
  326. *****************************************
  327.